We are migrating the bug tracker to github Issues. This is now the preferred way to report NASM bugs.

Self-registration is disabled due to spam issue (mail gorcunov@gmail.com or hpa@zytor.com to create an account)

Bug 3392640 - git nasm: condition code macro parameter as first of two parameters crashes nasm
Summary: git nasm: condition code macro parameter as first of two parameters crashes nasm
Status: CLOSED FIXED
Alias: None
Product: NASM
Classification: Unclassified
Component: Assembler (show other bugs)
Version: 2.15.xx
Hardware: All All
: Medium critical
Assignee: nobody
URL:
Depends on:
Blocks:
 
Reported: 2019-12-25 12:09 PST by E. C. Masloch
Modified: 2020-05-06 16:01 PDT (History)
4 users (show)

Obtained from: Built from git using configure
Generated by: ---
Bug category:
Observed for: ---
Regression: ---
Regression since:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description E. C. Masloch 2019-12-25 12:09:09 PST
The nasm command here is this revision https://repo.or.cz/nasm.git/commitdiff/e91f5cc1322eed4da0de81656276e021bf352c3d plus the patch given in https://bugzilla.nasm.us/show_bug.cgi?id=3392630#c1


$ cat test.asm
        %imacro mac 1-2
                j%+1
        %endmacro
        mac c, label

$ nasm -v
NASM version 2.15rc0 compiled on Oct 29 2019
$ nasm test.asm
Segmentation fault
$ oldnasm -v
NASM version 2.14.03rc2 compiled on Aug 31 2019
$ oldnasm test.asm
test.asm:4: error: invalid combination of opcode and operands
test.asm:2: ... from macro `mac' defined here
$ /usr/bin/nasm -v
NASM version 2.12.01
$ /usr/bin/nasm test.asm
test.asm:4: error: invalid combination of opcode and operands
$ 


The old versions correctly fail with an error here. The git nasm crashes instead.

It seems necessary to pass two macro parameters, the first one being a condition code, and that one being used with a %+1 or %-1 expansion.
Comment 1 Chang S. Bae 2020-02-06 13:07:10 PST
FYI, just bisected out and found this commit starts to get the segfault:

commit de7acc3a46cb3da52464d246b814f8bf059a0360 de7acc3a
Author: H. Peter Anvin (Intel) <hpa@zytor.com>
Date:   Mon Aug 19 17:52:55 2019 -0700

    preproc: defer %00, %? and %?? expansion for nested macros, cleanups
    
    BR 3392603: When doing nested macro definitions, we need %00, %? and
    %?? expansion to be deferred to actual expansion time, just as the
    other parameters.
    
    Do major cleanups to the mmacro expansion code.
    
    Reported-by: Alexandre Audibert <alexandre.audibert@outlook.fr>
    Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>


Obviously, this patch is fixing the old bug..
Comment 2 Chang S. Bae 2020-02-06 14:07:18 PST
(In reply to Chang S. Bae from comment #1)

It looks like this simple fix cures the issue:

diff --git a/asm/preproc.c b/asm/preproc.c
index 585843a4..d2154c13 100644
--- a/asm/preproc.c
+++ b/asm/preproc.c
@@ -4278,8 +4278,6 @@ static Token *expand_mmac_params(Token * tline)
                 unsigned long n;
                 char *ep;
 
-                text = NULL;
-
                 n = strtoul(t->text + 2, &ep, 10);
                 if (unlikely(*ep))
                     goto invalid;
Comment 3 Chang S. Bae 2020-05-06 16:01:55 PDT
This commit should have resolved the issue:


commit	7ee58d44e4df3f3097b9475dd0aafedecd428abd
author	Chang S. Bae <chang.seok.bae@intel.com>	
Wed, 25 Mar 2020 22:13:21 +0000 (25 15:13 -0700)
committer	Chang S. Bae <chang.seok.bae@intel.com>	
Tue, 21 Apr 2020 21:12:01 +0000 (21 21:12 +0000)
preproc: Fix the token in expanding the macro-parameters

The code looked to be unintentionally always nullifying the
token pointer at first place in handling those macro-parameters.
Remove it to avoid segfault.

Fixes: de7acc3a46cb ("preproc: defer %00, %? and %??
expansion for nested macros, cleanups")